The present invention relates to providing security for object-based computer software applications, and more particularly relates to limiting access privileges to a set of computer user identities.
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or functions for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers at a bank, and sales at a retail business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, product shipments, payments, or inventory for actions initiated by the individual users at their respective stations.
In a server application that is used by a large number of people, it is often useful to discriminate between what different users and groups of users are able to do with the server application. For example, in an on-line bookstore server application that provides processing services for entering book orders, order cancellations, and book returns, it may serve a useful business purpose to allow any user (e.g., sales clerks or customers) to access book order entry processing services, but only some users to access order cancellation processing services (e.g., a bookstore manager) or book return processing services (e.g., returns department staff).
Network operating systems on which server applications are typically run provide sophisticated security features, such as for controlling which users can logon to use a computer system, or have permission to access particular resources of the computer system (e.g., files, system services, devices, etc.) In the Microsoft Windows NT operating system, for example, each user is assigned a user id, which has an associated password. A system administrator also can assign sets of users to user groups, and designate which users and user groups are permitted access to system objects that represent computer resources, such as files, folders, and devices. During a logon procedure, the user is required to enter the user id along with its associated password to gain access to the computer system. When the user launches a program, the Windows NT operating system associates the user id with the process in which the program is run and with the process"" threads. When a thread executing on the user""s behalf then accesses a system resource, the Windows NT operating system performs an authorization check to verify that the user id associated with the thread has permission to access the resource. (See, Custer, Inside Windows NT 22, 55-57, 74-81 and 321-326 (Microsoft Press 1993).)
A thread is the basic entity to which the operating system allocates processing time on the computer""s central processing unit. A thread can execute any part of an application""s code, including a part currently being executed by another thread. Threads of a process share the virtual address space, global variables, and operating-system resources of the process. (See, e.g., Tucker Jr., Allen B. (editor), The Computer Science and Engineering Handbook 1662-1665 (CRC Press 1997).)
In object oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item""s properties with methods (e.g., program functions or procedures) to represent the item""s functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance.
Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related methods of the object. In other words, the client programs do not access the object""s data directly, but must instead call methods on the object""s interfaces to operate on the data.
Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.
A problem facing developers of object oriented applications is finding a way to implement a security scheme efficiently. For example, a developer of a banking application may want to prevent tellers from accessing an object for changing a customer""s deposit balance. However, the developer may be designing an application for use by a wide variety of banking organizations with different organizational structures and different employees. It would be a burdensome task for the application developer to customize the banking application for each of the banking organizations. Further, if user identities specific to the banking organization were placed in the objects"" logic, maintaining the application would require the further burden of changing the logic to account for employee turnover or reorganization.
A product addressing the problem of specifying access privileges to objects is provided by an application execution environment called Microsoft Transaction Server, a product separate from Windows NT which provides runtime services to application components.
Microsoft Transaction Server provides a mechanism called roles for defining an application""s security. Using roles, the application developer can specify a logical class of users (i.e., the role) permitted to access processing services of an application. The roles are independent of the system on which the application will be deployed. Subsequently, when the application is deployed on a host computer system, the deploying computer user (e.g., a security administrator) populates each role with particular users and groups. The roles are bound to the users and groups. In this way, the application developer can define security for the application without regard to what users and groups are recognized by the host computer system, and the administrator can tailor the security definition for a particular definition.
For example, a developer might put together a banking application by defining two roles: managers and tellers. In the application, the developer grants the managers role access privileges to components performing manager-related tasks; the tellers role is granted access privileges to components performing teller-related tasks. When the banking application is deployed, the administrator populates the managers and tellers roles with particular users and groups recognized by the host computer system (e.g., xe2x80x9cgsmithxe2x80x9d and xe2x80x9cteam1xe2x80x9d). Microsoft Transaction Server binds the users and groups to the application roles.
At runtime, Microsoft Transaction Server compares the identity of a user attempting to access an object with those bound to the object. Users not bound to the role granted privileges for the object are not permitted access to the object. Roles thus provide a developer with an efficient way to control access to application objects.
An advantage of object oriented programming is the ability to incorporate logic for a particular set of related functions into a single software component. Consequently, software developers can build an application by assembling a set of software components, reusing proven software components without having to reexamine their logic. The ability to reuse software components (sometimes called xe2x80x9creusabilityxe2x80x9d) leads to more efficient application development.
Sometimes, however, a single application does not perform all the functions desired by an organization. For example, a bookstore may purchase a first application for its shipping department to track customer shipments and returns. Meanwhile, the accounts payable division of the accounting department may require a second application with specialized functions to handle electronic payment to the book suppliers. The two applications may be combined (or xe2x80x9ccomposedxe2x80x9d) into an overall application, exchanging data among the software components.
For example, the shipping application can provide information about shipped orders and returns to the inventory application, to determine when to order more books or when to pay book suppliers. When two or more applications are combined into one overall application, the overall application is sometimes called an xe2x80x9cextended application,xe2x80x9d and the degree to which multiple applications can be combined into an extended application is sometimes called xe2x80x9ccomposability.xe2x80x9d
Maintaining security in an extended application poses certain challenges. Specifically, certain security problems arise when applications with roles are composed into an extended application.
For example, one application developer may have chosen xe2x80x9cmanagersxe2x80x9d for a role name, and another application developer may have instead used xe2x80x9cmgr.xe2x80x9d Although the roles may be conceptually equivalent, their titles are slightly different. At deployment time, the administrator ends up populating each role with the same users, unnecessarily duplicating work. Further, whenever a change in the organization requires a change to the role membership, the administrator must change both the xe2x80x9cmanagersxe2x80x9d and the xe2x80x9cmgrxe2x80x9d role, again leading to unnecessary work and possible confusion.
On the other hand, a developer might choose a title for a role that is already defined for another application. For example, one application developer may title a role for managers as xe2x80x9cteamAxe2x80x9d and another application developer may title a role for tellers as xe2x80x9cteamA.xe2x80x9d At deployment time, the administrator may confuse the two roles, which likely should be populated by different users and groups.
Further, an organization might deploy two applications with roles originally not thought to have a relationship. For example, a business application having the roles xe2x80x9cmanagersxe2x80x9d and xe2x80x9cengineersxe2x80x9d might be composed with a team management application having the roles xe2x80x9ccoachesxe2x80x9d and xe2x80x9cplayers.xe2x80x9d If the xe2x80x9cengineersxe2x80x9d role and the xe2x80x9cplayersxe2x80x9d role are filled by the same users and groups, again work is unnecessarily duplicated.
Finally, an organization might implement a scheme in which one set of users performs functions for two roles defined in a single application. For example, the shipping department might also handle customer returns. In an application in which xe2x80x9cshippersxe2x80x9d and xe2x80x9creturns staffxe2x80x9d roles are defined, the administrator would again have to populate the roles with the same users and groups and maintain the two roles separately.
Although roles such as those in Microsoft Transaction Server provide a way to define security independent of a particular computer system, they do not address the above scenarios in an efficient way.
The present invention includes a method and system for composing roles. An administrator can associate a first role with a second role, which takes on the population of the first role. Subsequent changes to the first role""s population are automatically implemented to the second role""s population. More than two roles can be associated, and the roles may be from the same or different applications. As a result, an administrator can perform one operation to bind a user to multiple roles.
In one aspect of the invention, the roles are bound to composite roles. The binding can be one to one, many to one, or one to many. The composite roles are populated with users, and users populating a composite role are considered to be members of the roles bound to the composite role. In this way, an administrator can populate a single composite role instead of individually populating separate application roles.
In another aspect of the invention, a security administrator can specify one role follows another role; the followed role becomes a composite role. Users added to a role are also added to any roles following it.
In another aspect of the invention, an application with new roles is installed on a computer system already having defined roles. The administrator can select which new roles, if any, should be composed with roles already on the computer system.
In still another aspect of the invention, a security framework is provided for implementing roles. The security framework consults a central store of security settings, including role definitions, to determine whether access to a component""s functionality is permitted. The framework blocks calls to objects if access is not permitted. The framework provides security logic outside the objects, so a developer is freed from having to develop security logic for the objects or within the objects. However, the framework provides programmatic access to role information so a developer can implement a custom security scheme with logic in the objects, if desired.
Additional features and advantages of the invention will be made apparent from the following detailed description of illustrated embodiments, which proceeds with reference to the accompanying drawings.